|Publication number||US7986630 B1|
|Application number||US 11/165,713|
|Publication date||Jul 26, 2011|
|Filing date||Jun 24, 2005|
|Priority date||Feb 9, 2004|
|Publication number||11165713, 165713, US 7986630 B1, US 7986630B1, US-B1-7986630, US7986630 B1, US7986630B1|
|Inventors||Siamack Nemazie, Shiang-Jyh Chang, Young-Ta Wu, Andrew Hyonil Chong|
|Original Assignee||Lsi Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (24), Non-Patent Citations (5), Referenced by (2), Classifications (6), Legal Events (9)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation-in-part of my previously-filed U.S. patent application Ser. No. 10/986,732, filed on Nov. 12, 2004 now U.S. Pat. No. 7,526,587 and entitled “Dual Port Serial Advanced Technology Attachment (SATA) Disk Drive”, which is a continuation-in-part of my U.S. patent application Ser. No. 10/775,523, filed on Feb. 9, 2004 now U.S. Pat. No. 7,539,797 and entitled “Route Aware Serial Advanced Technology Attachment (SATA) Switch” and is a continuation-in-part of my U.S. patent application Ser. No. 10/775,521, filed on Feb. 9, 2004 now U.S. Pat. No. 7,523,235 and entitled “Switching Serial Advanced Technology Attachment (SATA)”, and is a continuation-in-part of my U.S. patent application Ser. No. 10/775,488, filed on Feb. 9, 2004 now U.S. Pat. No. 7,523,235 and entitled “Serial Advanced Technology Attachment (SATA) Switch”, the disclosures of which are incorporated herein as though set forth in full.
The present invention relates generally to Fiber Channel (FC) target devices and in particular to target devices with dual FC ports and target bridge devices with dual FC ports that bridge the FC ports to another protocol such as Serial Advanced Technology Attachment (SATA) or Serial Advanced Technology SCSI (SAS) and achieving near maximum number of input/output (I/O) operation per second (IOOPS).
A “device” as used herein refers generally to a peripheral adhering to any known standard adopted by the industry. The term“target”, as used herein refers generally to a peripheral device, such as a hard drive, tape or any other such known devices. The term “target bridge”, as used herein is a network device coupled to a target via a target interface such as SATA or SAS and one or more hosts through a serial interface capable of performing protocol conversion, converting serial interface to SATA protocol for communication with the target SATA is a high-speed serial link replacement for the parallel Advanced Technology Attachment (ATA) attachment of mass storage devices. The serial link employed is a point-to-point high-speed differential link that utilizes multi-gigabit technology and 8b/10b encoding known to those of ordinary skill in the art. The SATA protocol is based on a layered communication model similar to Open Systems Interconnection (OSI) Reference Model. An overview is presented below. For more detail, the reader is referred to the SATA standard incorporated herein by reference. The SATA specification is provided in the publication entitled “Serial ATA: High Speed Serialized ATA Attachment” Revisions 1.0, dated Aug. 29, 2001, and the publication entitled “Serial ATA II: Extensions to Serial ATA 1.0”, Revision 1.0, dated Oct. 16, 2002, both of which are currently available at Serial ATA work group web site www.serialata.com.
The serial ATA link is defined by a protocol pursuant to a known standard, having four layers of communications, the physical layer for performing communication at a physical level, a link layer, a transport layer and an application layer or sometimes referred thereto as a command layer. A transmitter and a receiver, cannot directly communicate the latter with each other, rather, they must go through the other layers of their system prior to reaching a corresponding layer of the other. For example, for the physical layer of a transmitter to communicate with the transport layer of the receiver, it must first go through the link, transport and application layers of the transmitter and then through the serial ATA link to the application layer of the receiver and finally to the transport layer of the receiver. The basic unit of communication or exchange is a frame. A frame comprises of a start of frame (SOF) primitive, a frame information structure (FIS), a Cyclic Redundancy Checksum (CRC) calculated over the contents of the FIS and an end of frame (EOF) primitive. The serial ATA organization has defined a specification in which the definition of a frame is provided and which is intended to be used throughout this document. Primitives are double word (Dword) entities that are used to control and provide status of the serial line. The serial ATA organization has defined a specification in which the definition of allowed Primitives is provided and which is intended to be used throughout this document.
Fibre Channel (FC) is a standards-based networking architecture. The ANSI (American National Standards Institute) T11X3 committee is the governing body for FC standards. FC standards define a multilayered architecture for moving data across the network. The lower two layers, FC-1 and FC-0 also referred to as FC-Physical layer (FC-Phy) define media types, signaling, allowable lengths and media access. The FC-2 layer also referred to as link layer (FC-LL) defines how blocks of data will be segmented into sequence of frames, framing protocol, classes of service and flow control. The top layer FC-4 establishes interface between FC and the upper-level application
The topologies supported by fiber channel protocol include point-to-point, arbitrated look and switched fabric topologies. The Fiber Channel Arbitrated Loop (FC-AL) provides a middle ground between the point-to-point and fabric allowing connecting up to 126 ports on a single loop. In FC-AL, the transmit output of one port is connected to the receive input of the next. The process of connecting transmit output to receive output continues until a closed loop is formed. Problems inherent in any ring topology such as troubleshooting faulty lines or transceivers along the loop, connecting disconnecting devices to/from the loop promoted the development of centralized Arbitrated Loop (AL) hubs. AL hubs provide a physical star topology for a loop configuration, bringing each port's transmit and receive to a common location. The internal circuitry of a AL hub completes the required connections. One of the most useful features of a hub is bypass circuitry at each port, which allows the loop to circumvent a disabled or disconnected node while maintaining operation.
To prevent the potential for frame loss due to lack of available receive buffers at a port, fiber channel causes different levels of flow control to pace the rate at which the sender or transmitter is allowed to transmit frames. The first is a link level protocol called buffer-to-buffer (and a variation of buffer-to-buffer flow control used on virtual circuits called virtual circuit flow control) and an end-to-end flow control. All flow control protocols use a concept referred to as credit. Credit, as used herein, is defined as permission granted by a receiving port to a sending port to send a specified number of frames.
The number of frames that may be sent is referred to as available credit. As long as a port has a nonzero available credit, it has permission to send a number of frames equal to that of available credit. When a frame is sent, the available credit is decremented. When a response is received, the available credit is replenished. If the available credit reaches zero, frame transmission is suspended until the available credit is replenished to a nonzero value. Credit may be obtained in several ways depending upon class of service and topology. Transmission credit is initially established when two communicating nodes log in and exchange communication parameters. End-to-end flow control (EE_Credit) is used by Class 1 and Class 2 service between two end nodes and is monitored by the nodes themselves. An intervening switch does not participate in EE_Credit. Once an initial credit level is granted, the replenishment of credits is accomplished by acknowledgements (ACKs) issued by the receiver to the sender. The sender decrements the EE_Credit by 1 for each frame issued and increments only when an ACK is received. Buffer-to-buffer credit (BB_Credit) is issued by Class 2 and Class 3 services and relies on the receiver-ready (R_RDY) ordered set to replenish credits. BB_Credit has no end-to-end components. A sender decrements the BB_Credit by 1 for each frame sent and increments BB_Credit by 1 for each R_RDY received. The initial value of BB_Credit must be nonzero. In Arbitrated Loop, a different BB_Credit scheme is used. The BB_Credit assumes that the BB_Credit of a device is zero. The target node does not establish a positive BB_Credit until it is opened for a transaction by an initiator. The target then issues a number of R_RDYs equivalent to the receive buffer it has available. The differentiating feature of this BB_Credit is that an initiator does not have to maintain a table of BB_Credite values for potentially a large number of targets on the loop.
Fiber Channel Protocol (FCP) defines the mapping of popular SCSI command protocol to use fibre channel interface. This is the most widely used protocol mapping due to the popularity of the SCSI protocol combined with capabilities of fibre channel. The FCP mapping of SCSI to fibre channel defines information sets that are transferred between initiator and target. The information sets include: FCP_CMND, FCP_XFER_RDY FCP_DATA and FCP_RSP.
The FCP_CMND information set defines the data structure containing the SCSI command Descriptor Block and other command related information.
The FCP_XFER_RDY information set specifies the relative offset and length of the following data sequence.
The FCP_DATA information set is used to transfer data between an initiator and a target. The data may be sent as a single FCP_DATA information set, or broken up into multiple information sets.
The FCP_RSP information set defines the data structure containing the status response and signals the completion of command.
A target bridge 205 of prior art described in U.S. patent application Ser. No. 10/986,732, filed on Nov. 12, 2004 and entitled “Dual Port Serial Advanced Technology Attachment (SATA) Disk Drive”, is shown in
While the early generation of FC supported data rates of 100 Mega Bytes per Second (MBs) the current generation must support data rates of 100, 200 and 400 MBs and future generations are adapted to support 100, 200, 400 and 800 MBs and higher data rates. As data rates increase, the time to process frames is reduced. For example, at data rate of 100 MBs and a frame with a pay load of 2048 bytes, the frame transmission/reception will take about 21 usec and at data rate of 400 MBs, it will be reduced to about 5 usec. The target bridge needs to be able to manage frames without affecting performance. It is desirable that target bridge provide scalability from 100 MBs to 800 MBs without substantially affecting performance as measured by the number of Input/Output Operations Per Second (IOOPS). It is further desirable that such scalability is achieved with cost effective architecture.
Thus, there is a need for architecture and a method for use in dual port fiber channel target devices thereby enhancing scalability and performance. “Performance”, as used herein, refers to the number of input/output operations per second.
There is a further need to provide a method and architecture for substantially reducing the manufacturing costs and maintaining scalability and performance.
The invention incorporates features to eliminate or minimize real time response by processor to meet performance as measured by IOOPS and latency.
Storage devices, such as HDDs, are electromechanical devices with typical large latency due to seek time in command execution, storage devices typically support command queuing to allow performance optimization such as seek optimization. With a large FC command queue, the processor can process received commands in the background while the processor is waiting for an HDD response, and appropriately send queue commands to the HDD. A large FC command queue requires a large Rx buffer. One aspect of present invention include an apparatus and method for reducing size of required buffer while maintaining a large FC command queue. Another aspect of present invention eliminates processor intervention in data transfer phase of command execution.
Briefly, an embodiment of the present invention includes a dual port fiber channel target device including a single processor subsystem with high performance. One aspect of the invention is an apparatus and method for a dynamic credit management to allow host to send a large number of commands without requiring the total buffer size to exceed the command queue size. Another aspect of invention include an architecture, apparatus and method to offload the processor subsystem for managing data transfer associated with command execution.
The processor subsystem 470 is shown to include a processor 471, coupled via bus 471 b to a bus interface (IF) unit 472, an instruction Random Access Memory (RAM) 475, a data RAM 476, a Read-Only-Memory (ROM) 474, a serial non-volatile-memory (NVM) IF 477, and one or more peripherals 473. The serial NVM IF 477 is shown coupled to a NVM 478 through a serial interface 478 a. In an alternative embodiment, the instruction RAM 475 and data RAM 476 are combined into a single RAM structure. The instruction RAM 475 is generally for storing instructions or firmware or software code, such that when executed, direct the performance of one or more tasks.
Instructions, such as computer software or firmware code, is loaded into the instruction RAM 475 from the serial Flash 478 via serial Flash IF 478 a upon powering on of the system or initialization thereof. This allows instructions to be executed from a fast memory (i.e. RAM) to avoid wait states and allows single cycle execution of instructions. In alternative embodiments, a parallel NVM interface is used for achieving the same. Examples of NVM include Flash Memory or EEPROM or any other type of memory capable of maintaining data or information stored therein even when power is not supplied thereto. The bus interface unit 472 couples the processor subsystem 470 to external units via the bus 479. Examples of peripherals or external units include an interrupt controller, a General Purpose IO (GPIO) controller, Timer units, Clock generation units, a serial interface unit, and parallel interface unit.
The FC port 411 is shown coupled to the FC link 407 and includes a fiber channel physical layer (FC-Phy) 412, a fiber channel link layer controller (FC-LLC) 414, a transmit frame manager 416, a transmit (Tx) frame first-in-first-out (FIFO) 418, a receive (Rx) frame FIFO 420, and a receive (Rx) frame manager 422 coupled together as shown in
The structure and coupling of the FC port 431 and all of the other FC port 431 devices are similar to that described hereinabove with respect to the FC port 411. That is, the FC port 431 is shown to be coupled to a FC link 408 and includes a FC-Phy 432, a FC-LLC 434, a Tx frame manager 436, a Tx frame FIFO 438, a Rx frame FIFO 440 and a Rx frame manager 442 coupled together as shown in
The buffer and DMA 490 is shown to include a data buffer 492 coupled to a Streaming DMA engine 494 via the bus 493 and a data buffer 496 coupled to a Streaming DMA engine 498 via the bus 497.
The device port 451 is shown to include a SATA Phy Layer 452, a SATA Link Layer 454, a SATA Transport Layer 456, and a SATA command layer 458. The device port 451 is shown coupled to a SATA link 409. The device port controller 461 is shown to include a register file 462, which is shown coupled to the SATA Command Layer 458 via the bus 469 d. The device port controller 461 is further shown to include a mapping and control circuit 464 and a scratch buffer 465. The register file 462 is further shown to include a Task file 462 a. The device port controller 461 is coupled to the buffer and DMA circuit 490 via the bus 469 b. The processor subsystem 470 accesses configuration, control and status registers in the device port controller 461 via bus IF unit 472 and the bus 479.
Information received, processed and transmitted by the device FC ports 411 and 431 is generally in the form of frames. Frames include, but are not limited to, header, payload and CRC field. Frame types include, but are not limited to, command frames, basic link services or extended link services (collectively link services) frames, common fibre channel service frames, arbitrated loop initialization frames and data frames.
The Rx operation of FC port 411 will be discussed next. The FC port 411 appends a Rx frame control word to the header of received frames and stores the result in the Rx buffer 426. For command, link services, or arbitrated loop initialization frames, the frame payload is stored in the Rx buffer 426. For all other frames, the payload is stored in the data buffer 492. The Rx frame descriptor specifies the structure of the Rx frame in the Rx buffer 426.
The Rx operation of FC port 431 is similar to that described hereinabove with respect to the FC port 411. Referring back to
The Rx frame descriptor specifies the structure of the Rx frame in the Rx buffer 446. As earlier described,
Information received, processed and transmitted by the device FC ports 411, and 431 is generally in the form of frames. Frames include header, payload and CRC field. Frame types include command frames, link services frames, arbitrated loop initialization frames and data frames In
Whenever a ‘credit’ is provided by Rx frame manager, there need be assurances of enough or ample buffer size to accommodate the largest type of frame that may be received. In order to queue large number of commands, a large Rx buffer size is used for storing frames received from the initiator. Commands, once stored in the buffers 426 and 446, are provided to the microprocessor (or processor) 471 through the bus 479 for execution thereof by the microprocessor 471. In this manner, many commands are queued without risking potential loss of commands. This type of buffering and decoding of the commands removes the need for real-time processing by the microprocessor 471. It is for the foregoing reason that only one processor is needed rather than the two-processor approach of prior art devices/systems. However, a larger size buffer is required than that of prior art systems.
An example perhaps serves to better understand of the notion provided hereinabove. For the sake of assumption, suppose that 128 commands are to be queued. A credit is to be provided by Rx frame manager which indicates that a frame, may be received, however, as there is no way of knowing which type of frame is to be received, the device 405 must be able to accommodate even the largest of frame sizes, i.e. those of data or other types of frames. Thus, the size of the buffers 426 and 446 need be large enough to accommodate the largest of frame sizes.
Referring to the same example, to queue 128 commands, which each include 60 bytes, there is a requirement of 128×60 bytes or 7,680 bytes needed for storing the commands. However, to account for the largest size frame, i.e. data or other types of frames, which may each be 2076 bytes in size, a space of 128×2048+128×120=277,504 bytes or approximately 278 Kilo Bytes (KB) is required as the total buffer size (Rx buffer plus data buffer). Therefore, to ensure accommodations for the largest size frames, a total buffer size of about 278 KB is required.
However, the problem of large buffer sizes is resolved by the device 405 through dynamic credit allocation or credit management. That is, the size of the buffer is based, in part, upon the number of credits allocated plus extra buffer for queuing up to a maximum command queue. For example, if the buffer 426 or 446 is to store 128 command frames that are 60 bytes each and there is a credit of 30 provided, then a total buffer size of approximately 30×2048+[30×120+(128−30)×60]=70,920 bytes or 71 KB is required. The size of the Rx buffer is [30×120+(128−30)×60]=9,480 bytes and the size of data buffer is 30×2048=61,440 bytes for a total buffer size of approximately 71 KB. In prior art systems, the total buffer size needs to be approximately 278 KB. There is therefore a substantial reduction of total buffer size with one of the embodiments of the present invention.
The Rx frame manager (RFM) maintains 3 counters to properly manage dynamic credit management. A counter M indicates the number of available command frames in Rx buffer. A counter N indicates the number of available frames other than command frames. A counter K indicates the difference between buffer available and credits issued for non-command frames after an open connection has been established.
A flow chart for dynamic credit management is shown in
At step 620, where the connection is closed, the RFM resets K to zero and sets the connected flag to logical value of zero to indicate that the connection is removed and the process continues to step 622. At step 624, where the processor released J, non-command entries in the Rx frame buffer, the RFM adds J on N and K (N=N+J, K=K+J) and if M>N, then RFM issues K credits and resets K to zero, and the process continues to step 626. At step 626, where the processor released J, non-command entries in the Rx frame buffer, the RFM adds J on M (M=M+J), and if M>N, then RFM issues K credits and resets K to zero, and the process continues to step 630.
Since issuing large amount of credits (i.e. sending R_RDYs) is a delay-intensive process due to the transmission of frames by the Tx frame manager 416, the flow chart 601 can be modified to allow arbitration between the pending request from the Tx frames manger 416 and the credit manager 503. One such arbitration method is to first give priority to the credit manager 503 and after issuing a predetermined number of credits, the priority is given to the Tx frame manager 416 and after the frame transmission gives priority back to the credit manger, the process continues changing priority, as described hereinabove. There are many other arbitration schemes which fall within the scope of this invention. An example of credit management perhaps will serve to better understand the same.
For the sake of supposition, let us assume that M=128, N=32 and K=0 and that at the outset, 32 credits are granted with K=0. Lets suppose that 20 non-command frames are received by the device 405, then M=128, N=12, K=0 and the host has 12 remaining credits available.
Lets further suppose that 18 command frames are received, then M=110, N=12, K=0 and the initiator still has 12 remaining credits available since for each command that was received, the target hardware grants one credit to the host.
Now, assuming that execution of firmware by the microprocessor 470 has caused completion of processing of 8 non-commands and releases these entries or memory spaces within the receive buffer, i.e. the buffer 426 or 446, then M=110, N=20, and K=8. Since M>N, 8 credits are granted, K is reset to 0 and the initiator will have 20 credits available.
Suppose still further that execution of the firmware has caused completion of processing of 10 commands and has released the commands' entries, then M=120, N=20, and K=0. Since M>N but K=0, no additional credit is issued and the initiator or host has 20 available credits.
Dynamic credit management takes into consideration and processes the commands and link services frames so as to take advantage of actions dictated by the host. That is, for example, if following a command, the link services frame indicates aborting the command, obviously, such an action is taken with no further need for maintaining the command. To this end, the command frames and link services frames are stored together. Accordingly, the receive buffer 426 or 446 stores the command frame and LS/ELS but not the data frames.
Using the example above, initially, M is 128 and N is 16 and K is 0. When a connection is established minimum (M,N)=minimum (128, 16)=16 credits is issued. When the host (not shown in
When a non-command frame is received from the host or initiator, no credit is granted. Thus, upon receipt of a link services frame, no credit is provided and N is decremented by one.
At some point in time, after having received a certain number of commands or non-commands, the microprocessor 471 starts to process the received frames and upon doing so, the frames, whether command and/or link services frames are released from the buffer 426 or 446 and the space in which these frames resided is released and becomes available. This is referred to as firmware release frames. If the released space (the number of released spaces is represented by the value ‘J’) is updated, no credit is provided or issued. At this point, for non-commands, K=K+J and N=N+J and if M is greater than N (the number of available space in the command queue is larger than the space available in the buffers other than the command buffers) then K credits are granted and K is set to ‘0’. When J spaces are released, for commands, M=M+J and then K credits are granted and K is set to ‘0’.
The goal is to ensure that the total outstanding credit is not larger than the number of available spaces in the buffers. A predetermined portion of the receive buffer is allocated to store non-command frames and another predetermined portion thereof is allocated for storing command frames. The goal is to prevent the space from exceeding the number of credits provided to the host. Thus, the total number of credits granted to the initiator or host cannot exceed the number of free spaces in the receive buffer, such as the buffer 426 or the buffer 446. So long as this condition is met, the host is provided credit. In this manner, the number of credits is decided; the more credits that can be granted without violating the foregoing rule, the more credits that will be issued.
The foregoing process is performed by execution of firmware, stored in the RAM 475, by the processor 471. During releasing of spaces occupied by the command and/or LS/ELS frames, by execution of firmware, the microprocessor 471 moves the stored command and/or LS/ELS frames from the buffers 426 and 446 to the data RAM 476.
The credit handling process, performed by the device 405, allows for different frame types having different frame sizes to be handled using only one processor. It should be understood that numbers provided herein are merely for the purpose of providing an example and are in no event to be construed as a limitation of any of the embodiments of the present invention.
Credit is managed in a manner so that at no time is there a possibility for the host to send frames when no buffer space is available. At the same time, the goal is to store more of one type of frame than the other types. In this manner, credit is provided for those types of frames that are desirable as soon as such a frame type is received, whereas, less desirable types of frames are not immediately afforded such courtesy in that a credit does not immediately follow receipt of less desirable frames.
In one embodiment of the present invention, command frames are more desirable by the host and they, upon receipt thereof, cause immediate credit therefor. The reason for the preference of command frames is that they can be stored in the receive buffer and processed later thereby avoiding the need for two processors. That is, only one processor is necessary, such as the microprocessor 471 of
Examples of the different HDD interfaces are Serial ATA, ATA.
It should be noted that in
The FC DMA & control 522 a and SATA DMA & control 522 b use a linked list for the DMA. Typically DMA operation specifies a starting address in buffer and a transfer count. A linked list DMA allows linking multiple non-contiguous buffer segments for the DMA operation, wherein each buffer segment is specified by a pointer and size. The DMA link list is maintained in the DBLT 523. The DBLT 523 includes plurality of DBLT entries. A DBLT entry corresponds to a fixed size buffer segment. DBLT entry 0 corresponds to buffer segment 0, DBLT entry 1 corresponds to buffer segment 1 and so forth. The structure of DBLT entry 524 is shown in
The free list manager 525 manages a list of free buffer segments within data buffer. The free list manager 525 is shown to include a head of free list 526, a tail of free list 527 and a free segment count 528. The free list manager 525 is coupled to FC DMA and control 522 a, and SATA DMA and control 522 b via bus 525 a and 525 b respectively, these buses including request to get free buffer, or reserve free buffer and responses. The free list manager performs the following functions:
The streaming DMA information is maintained in context descriptor buffer (CDB) 529. The CDB has an CDB entry 530 for every streaming DMA identified by Tag assigned by the processor 471. The structure of CDB entry 530 is shown in
The structure of FC transfer pointers field 535 is shown in
The structure of SATA transfer pointers field 536 is shown in
The structure of streaming control field 534 is shown in
The structure of flag field 534 d is shown in
The structure of next command link field 534 c is shown in
The structure of flag field 534 b is shown in
The SATA DMA and control 522 b initiates the FC DMA transfer by asserting FC Read (Rd) Streaming 521 a, or FC Write (Wr) Streaming 521 b, along with a Tag 521 c which is the CDB entry 530 in the CDB buffer 529 corresponding to the command
The flow chart of SATA read streaming DMA is shown in
After obtaining a free data buffer segment pointer, the process continues to step 718 and a DMA operation is performed from SATA to the data buffer segment referenced by the pointer obtained. After the completion of DMA or filling, the data buffer segment continues to step 722. At step 722, the context descriptor fields are updated including transfer count (TC) 532, and process continues to step 728. At step 728, if the FC transfer threshold is reached, the FC Rd streaming 521 a is asserted along with outputting Tag value on Tag signals 521 c and step 730 is executed.
In this embodiment, the FC transfer threshold is reached if a predefined percentage of total transfer count is in the data buffer or a predefined amount of data is in the data buffer or the buffer is full. At step 730, the TC is checked to determine whether or not it has reached the value zero. If at step 730, the TC is determined to have reached zero, the process continues to step 737, otherwise, the process continues to step 732. At step 732, a free data buffer segment pointer is obtained from the free list manager 525. After obtaining a free data buffer segment pointer at step 732, the process continues to step 734, saving the pointer in the NDBP field of current DBLT entry, storing the amount of data transferred at step 718 (which in this case is equal to buffer segment size) in the CSPZ field of current DBLT entry and setting the V flag and NDBPV flags of the current DBLT entry to a logical value of 1.
After completing step 734, to the process continues to step 718 and, repeats the above operations until at step 730, the TC reaches zero, at which point the process continues to step 737. At step 737, the amount of data transferred at step 718 is stored in the CSPZ field of current DBLT entry, the V flag and E flags of the current DBLT entry are set to a logical value of 1 and the process continues to step 738.
Setting the E flag of current DBLT entry at step 734 indicates that this entry is the last entry in the linked list of DBLT entries. At step 738, it is determined whether or not a new SATA read transfer is requested. If a new SATA read is not requested, the process continues to step 710 and waits for a new SATA read request, otherwise, the process continues to step 740 and checks if the current FC read operation is completed, that is, if the FC streaming flag is set to logical value 0, in which case the process continues to step 712, otherwise, the process moves to step 742 and updates the next command link field 534 c of the CDB entry. At step 742, the NV flag is set to logical value 1 and the Tag value of the new command is saved in the NST field. After completing step 742, the process continues to step 712 and proceeds as described above.
At step 757, the E flag 524 d of the DBLT entry 524 is checked, if the E-flag is a logical value 1, which indicates that no more frame transmission is required, the process proceeds to step 762, otherwise, the process proceeds to step 758. At step 758, a wait cycle is entered until the NDBPV flag 524 e is at a logical value of 1, which indicates that the pointer NDBP 524 b is valid, and then the process continues to step 759.
At step 759, the NDBP 524 b is saved in the FC LBP field 535 a of the CDB entry 530, and process proceeds to step 760. At step 760, a wait cycle is entered for completion of frame transmission and, next, a request is made to free the list manger 525 to release the buffer segment, and then proceed to step 754 repeating the above process until at step 757, the E flag 524 d of the DBLT entry 524 is at a logical value of 1, indicating no more frame transmission is required.
Next, at step 762, another wait cycle is entered waiting for transmission of the last frame, and then sending a request to free the list manger 525 to release the buffer segment, and then setting the PC flag 534 to a logical value of 1 and then continuing to step 764. At step 764, the NV flag 534 is checked for logical value 1, which would indicate that a SATA transfer for another queued command is in progress and next, the process continues to step 766.
At step 766, the DV flag 534 is reset and the next CDB entry 530 corresponding to next tag NST field 534[20:16] is fetched, proceeding to step 754. At step 764, if the NV flag 534 is at logical value 0, the process continues to step 768, the FC streaming is reset and then the process continues to step 750.
Next, at step 854, the DV flag 534 is checked for a valid descriptor. If the DV logical value is 0, an invalid descriptor is indicated and the process proceeds to Error (Err) State, otherwise, the process goes to step 864. At step 864, the DBLT entry 524 corresponding to the SATA LBP 536 a is fetched, and the V flag 524 c is checked for a value of 1 which would indicate valid data is available in the buffer segment. If the V flag 524 c is a logical value 1, the process continues to step 866, otherwise, step 864 is repeated until the V flag 524 c is at a logical value of 1. At step 866, a DMA operation is performed from data buffer segment referenced by the pointer to SATA. After completion of the DMA operation, the process continues to step 868. At step 868, the E flag 524 d of the DBLT entry is checked and if the E flag is determined to be at logical value 1, indicating a last DBLT entry on the linked list, the process proceeds to step 880, otherwise, the process proceeds to step 870.
At step 870, the NDBPV flag 524 e is checked and if determined to be logical value 0, step 870 is repeated until the NDBPV flag 524 e is determined to be at logical value 1 and the process proceeds to step 872. At step 872, the NDBP field 524 b is stored in the SATA LBP field 536 of the CDB entry 530, and the process goes back to step 864. At step 880, the PC flag 534 is set to logical value 1 and the DV flag 534 is set to logical value 1 and the process goes back to step 850.
At step 818, a free data buffer segment pointer is obtained from the free list manager 525. After obtaining a free data buffer segment pointer, the process continues to step 822. At step 822, the FCP_XFR_RDY frame is built and sent to the Tx frame manger for transmission thereof. The FCP_XFR_RDY frame causes a request of the data frame to be sent to the FC bridge.
At step 824, the process awaits receipt of a data frame and continues to step 826 to check for a match between the received data frame header and the expected frame header in the CDB. If a mismatch is determined, the process goes back to step 824 waiting for data frame, otherwise, the process continues to step 828. At step 828, the data frame payload is sent through a DMA operation to the data buffer segment referenced by the obtained pointer. After the completion of the DMA operation, the process proceeds to step 834. At step 834, the CDB entry fields are updated including a transfer count (TC) and then the process continues to step 836.
At step 836, the TC is checked for reaching the value zero. If at step 836, it is determined that the TC has reached zero, the process continues to step 848, otherwise, the process continues to step 838. At step 838, the amount of data transferred at step 828 in the CSPZ field of the current DBLT entry is stored, the V flag of the current DBLT entry is set to a logical value of 1 and the process continues to step 840.
At step 840, a free data buffer segment pointer is obtained from the free list manager 525. After obtaining a free data buffer segment pointer, the pointer in the NDBP field of current DBLT entry is saved, the NDBPV flag of the current DBLT entry is set to a logical value of 1. After completing step 840, the process continues to step 842. At step 842, the frame is checked as to whether it was the last frame of the sequence and if so, the process goes back to step 816, otherwise, the process goes back to step 824. The above operation is repeated until at step 836, the TC reaches zero, at which point the process continues to step 848.
At step 848, the amount of data transferred at step 828 in the CSPZ field of current DBLT entry is stored, the V flag and E flags of the current DBLT entry are set to a logical value of 1 and the process continues to step 810. Setting the E flag of current DBLT entry at step 848 indicates that this entry is the last entry in the linked list of DBLT entries.
The write streaming operation has a latency between SATA write request and receiving first data frame from FC after initiating FC transfer. In order to eliminate or minimize this latency, the write data or a portion of write data can be prefetched prior to receiving the SATA write request. In another embodiment the step 810 can modified to check either FC streaming flag or prefetch flag 534. When the prefetch flag is set the FC treaming is initiated, a predetermined amount of write data is prefetched and when the SATA Wr request is received some amount of write data is in the buffer and SATA transfer can commence without latency while the FC write streaming will resume and the operation will continue as described above.
The above invention has been described for the case that the logical block sizes on the host commands and the sector size on the HDD are the same, for example 512 bytes. Specifically there are practical applications where the logical block sizes and sector size are different. An example is when logical block sizes are 520 or 528 byte and the sector size on HDD is 512. It is obvious for one skilled in the art to use the teaching of this invention and apply to the case that logical block sizes are 520 or 528 and the sector size on HDD is 512. Such extension fall within the scope of the invention
One of the applications of the embodiments of the present invention includes fast FC data rates and high-performance HDD having a very short seek time wherein a two-processor system is utilized.
The processor subsystem 370 is shown to include a processor (or microprocessor) 371, coupled via bus 371 b to a bus interface (IF) unit 372, a data RAM 376 (for storing data), an instruction RAM 375 (for storing program code), a Read-Only-Memory (ROM) 374, a serial non-volatile-memory (NVM) IF 377, and one or more peripherals 373. The serial NVM IF 377 is shown coupled to a NVM 378 through a serial interface 378 a. In an alternative embodiment, the instruction RAM 375 and data RAM 376 are combined into a single RAM. Instructions or program code is loaded into the instruction RAM 376 from the serial Flash 378, via the serial Flash IF 378 a, upon power-on initialization. This allows instructions to be executed from a fast memory (i.e. RAM) to avoid wait states and to allow single cycle execution of instructions.
In alternate embodiments, a parallel NVM interface is used. Examples of NVM include Flash Memory or EEPROM. The bus interface unit 372 couples the processor subsystem 370 to external units via bus 379. Examples of peripheral include interrupt controller, General Purpose 10 (GPIO) controller, Timer units, Clock generation units, serial interface unit, and a parallel interface unit.
The structure, operation and coupling of the processor subsystem 380 are similar to that described hereinabove with respect to the processor subsystem 370. That is, the processor subsystem 380 is shown to include a processor 381, coupled via bus 381 b to a bus interface (IF) unit 382, a data RAM 386, an instruction RAM 385, a ROM 384, a serial NVM IF 387, and peripherals 383. The serial NVM IF 387 is shown coupled to a NVM 388 through a serial interface 388 a.
The FC port 311 is shown to include a FC link 307, a fiber, channel physical layer 312, a fiber channel link layer controller (LLC) 314, a transmit frame manager 316, a transmit (Tx) frame first-in-first-out (FIFO) 318, a receive (Rx) frame FIFO 320, a receive (Rx) frame manager 322 coupled together as shown in
The structure and coupling of the FC port 331 and all of the other FC port 331 devices are similar to that described hereinabove with respect to the FC port 311. That is, the FC port 331 is shown to include a FC link 308, a fiber channel physical layer 332, a fiber LLC 334, a Tx frame manager 336, a Tx frame FIFO 338, a Rx frame FIFO 340, a Rx frame manager 342 coupled together as shown in
The buffer and DMA 390 is shown to include a data buffer 392 coupled to a Data Memory Access (DMA) engine 394 via the bus 393 and a data buffer 394 coupled to a DMA engine 396 via the bus 395.
The device port 351 is shown to include a SATA Phy Layer 352, a SATA Link Layer 354, a SATA Transport Layer 356, and a SATA command layer 358. The device port 351 is shown coupled to a SATA link 309. The device port controller 361 is shown to include a register file 362 coupled to SATA Command Layer 358 via the bus 369 d and a mapping circuit 364. The register file includes a Task file 362 a and a control/status (CS) registers 362 b. The device port controller 361 is coupled to the buffer and DMA 390 via the bus 369 c. The processor subsystem 370 accesses the configuration, control and status registers in the device port controller 361 via the bus IF unit 372 and the bus 379. The processor subsystem 380 accesses the configuration, control and status registers in the device port controller 361 via the bus IF unit 382 and the bus 389.
Although the present invention has been described in terms of specific embodiments it is anticipated that alterations and modifications thereof will no doubt become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted as covering all such alterations and modifications as fall within the true spirit and scope of the invention. It is obvious to an expert in the art to combine the present invention with prior art to develop devices and methods that perform multiple functions including the teachings of this invention. Such devices and methods fall within the scope of present invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5440752||Jul 8, 1991||Aug 8, 1995||Seiko Epson Corporation||Microprocessor architecture with a switch network for data transfer between cache, memory port, and IOU|
|US5610745 *||Oct 26, 1995||Mar 11, 1997||Hewlett-Packard Co.||Method and apparatus for tracking buffer availability|
|US5946322 *||Aug 27, 1996||Aug 31, 1999||Hybrid Networks, Inc.||Hybrid access system utilizing credit/done polling protocols|
|US6038235 *||Aug 20, 1997||Mar 14, 2000||Sun Microsystems, Inc.||Fiber channel automatic arbitration and communication control|
|US6247100||Jan 7, 2000||Jun 12, 2001||International Business Machines Corporation||Method and system for transmitting address commands in a multiprocessor system|
|US6279057 *||Nov 17, 1998||Aug 21, 2001||Seagate Technology, Inc.||Communications system having dedicated frame buffers located in a channel node connected to two ports of the channel node for receiving frames|
|US6388590||Sep 24, 1999||May 14, 2002||Oak Technology, Inc.||Apparatus and method for transmitting data serially for use with an advanced technology attachment packet interface (atapi)|
|US6434620||Aug 27, 1999||Aug 13, 2002||Alacritech, Inc.||TCP/IP offload network interface device|
|US6735650||Aug 30, 2002||May 11, 2004||Western Digital Technologies, Inc.||Disk drive and method for data transfer initiated by nonstandard disk-drive commands on a serial ATA interface that only supports standard ATA disk-drive commands|
|US6763402||May 24, 2001||Jul 13, 2004||Bnl Technologies, Inc.||Data storage subsystem|
|US7154905||Nov 7, 2001||Dec 26, 2006||Silicon Image||Method and system for nesting of communications packets|
|US20030033465||Aug 8, 2001||Feb 13, 2003||Cheng-Chih Chien||Hot-swap device applicable to ATA interface|
|US20030131166||Oct 18, 2002||Jul 10, 2003||Fujitsu Limited||Information processing system and interface apparatus|
|US20030236953||Feb 25, 2003||Dec 25, 2003||Compaq Information Technologies Group, L.P.||System and method for providing multi-initiator capability to an ATA drive|
|US20040027987 *||Jul 25, 2002||Feb 12, 2004||Andiamo Systems, Inc.||Methods and apparatus for credit-based flow control|
|US20050050240 *||Aug 6, 2004||Mar 3, 2005||Virgil Wilkins||Integrated input/output controller|
|US20050120150||Apr 2, 2004||Jun 2, 2005||Advanced Micro Devices, Inc.||Buffer sharing in host controller|
|US20050198425||Mar 5, 2004||Sep 8, 2005||Wang Liang-Yun||Combined optical storage and flash card reader using single ide or sata port and method thereof|
|US20060031612||Aug 3, 2004||Feb 9, 2006||Bashford Patrick R||Methods and structure for assuring correct data order in SATA transmissions over a SAS wide port|
|US20060095608 *||Oct 29, 2004||May 4, 2006||Pak-Lung Seto||Buffer utilization in a frame based communication system|
|US20060136666||Oct 11, 2005||Jun 22, 2006||Ching-Te Pang||SAS storage virtualization controller, subsystem and system using the same, and method therefor|
|US20060174049||Sep 8, 2005||Aug 3, 2006||Sunplus Technology Co., Ltd.||USB to SATA bridge system|
|US20060271739||Sep 7, 2005||Nov 30, 2006||Shu-Fang Tsai||Management of transfer of commands|
|TW507896B||Title not available|
|1||Klaus-Peter Deyring, Serial ATA: High Speed Serialized AT Attachment, Serial ATA Workgroup, Jan. 7, 2003, p. 1-35, Santa Cruz, USA, XP002393220.|
|2||Robert C. Elliot, Working Draft American National Standard: Information Technology Serial Attached SCSI-1.1 (SAS-1.1), Project T10/1601-D; Rev. 9e Jul. 24, 2005, Houston, Texas, USA; Reference No. ISO/IEC 14776-151:200x.|
|3||Robert C. Elliot, Working Draft American National Standard: Information Technology Serial Attached SCSI-2 (SAS-2), Project T10/1760-D; Rev. 6 Sep. 22, 2006, Houston, Texas, USA; Reference No. ISO/IEC 14776-152:200x.|
|4||SATA IO Board Members: Dell Computer Corporation, Hewlett Packard Corporation, Hitachi Packard Corporatioin, Hitachi Global Storage Technologies, Inc., Intel Corporation, Maxtor Corporation, Seagate Technology, Vitesse Semiconductor Corporation, Serial ATA International Organization: Serial ATA Revision 2.5, Oct. 27, 2005.|
|5||SATA IO Board Members: Dell Computer Corporation, Hewlett Packard Corporation, Hitachi Packard Corporatioin, Hitachi Global Storage Technologies, Inc., Intel Corporation, Maxtor Corporation, Seagate Technology, Vitesse Semiconductor Corporation, Serial ATA International Organization: Serial ATA Revision 2.6, Feb. 15, 2007.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8078771 *||Dec 5, 2008||Dec 13, 2011||Lsi Corporation||Sending large command descriptor block (CDB) structures in serial attached SCSI (SAS) controller|
|US20100115152 *||Dec 5, 2008||May 6, 2010||Day Brian A||Sending large command descriptor block (CDB) Structures in serial attached SCSI(SAS) controller|
|U.S. Classification||370/236, 370/230.1, 370/470|
|Cooperative Classification||G06F2213/0032, G06F13/4247|
|Jun 24, 2005||AS||Assignment|
Owner name: SILICONSTOR, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NEMAZIE, SIAMACK;CHANG, SHIANG-JYH;WU, YOUNG-TA;REEL/FRAME:016727/0324
Effective date: 20050623
|Oct 5, 2007||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: MERGER;ASSIGNOR:SILICONSTOR, INC.;REEL/FRAME:019927/0098
Effective date: 20070621
|Feb 24, 2009||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHONG, ANDREW HYONIL;REEL/FRAME:022305/0350
Effective date: 20081210
|May 8, 2014||AS||Assignment|
Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AG
Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:LSI CORPORATION;AGERE SYSTEMS LLC;REEL/FRAME:032856/0031
Effective date: 20140506
|Mar 6, 2015||REMI||Maintenance fee reminder mailed|
|Apr 3, 2015||AS||Assignment|
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LSI CORPORATION;REEL/FRAME:035390/0388
Effective date: 20140814
|Jul 26, 2015||LAPS||Lapse for failure to pay maintenance fees|
|Sep 15, 2015||FP||Expired due to failure to pay maintenance fee|
Effective date: 20150726
|Feb 2, 2016||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201
Owner name: AGERE SYSTEMS LLC, PENNSYLVANIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201